This invention generally relates to data processing systems and methods, and more specifically, to object oriented computing environments.
Object oriented programming systems and processes, also referred to as “object oriented computing environments”, have been the subject of much investigation and interest in state of the art data processing environments. As is well known to those having skill in the art, object oriented programming systems are composed of a large number of “objects”. An object is a data structure, also referred to as a “frame”, and a set of operations or functions, also referred to as “methods”, that can access that data structure. The frame has many “slots”, each of which contains an “attribute” of the data in the slot. The attribute may be a primitive (such as an integer or string) or an object reference which is a pointer to another object. Objects having identical data structures and common behavior can be grouped together into, and collectively identified as, a “class”.
Each defined class of objects will usually be manifested in a number of “instances”. Each instance contains the particular data structure for a particular example of the object. In an object oriented computing environment, the data is processed by requesting an object to perform one of its methods by sending the object a “message”. The receiving object responds to the message by choosing the method that implements the message name, executing this method on the name instance, and returning control to the calling high level routine along with the results of the method. The relationships between classes, objects and instances are established during “build time” or generation of the object oriented computing environment, i.e. prior to “run time” or execution of the object oriented computing environment.
As described above, object oriented programming systems are composed of a large number of objects. The amount of data and processing accommodated by an object is typically small enough to be contained within a single row of a database table or a single data entry panel. However, it will be recognized by those having skill in the art that a user view of an object may be considerably more complicated. Thus, simple objects may be tightly bound together as a Complex Object because they all participate in a business process. Alternatively, simple objects may be tightly bound as a Complex Object for purposes of data navigation and presentation or because of cross-object data verifications.
Additional background information about complex objects in an object oriented computing environment is given in U.S. Pat. No. 5,832,268, the disclosure of which is hereby incorporated herein by reference.
An important problem (see FIG. 3) solved by EADP complex object support is the scattering of relational data due to normalization. Traditionally a lot of application logic is devoted to reassembling this data for presentation, and also to providing navigation paths to drill down through the data. Much of this logic is very similar from one application to another. EADP provides runtime support for many of these common application tasks (complex object navigation, presentation of normalized data through quick views, calculation of computed fields, calculations of summary fields, and context control through the ruler list). EADP also provides build time support so that an application can be adapted to use these features using custom editors for Java beans.